Additional interceptors: onEnter + onLeave#586
Additional interceptors: onEnter + onLeave#586rubenvereecken wants to merge 2 commits intovfsfitvnm:masterfrom
Conversation
src/memory.ts
Outdated
| } | ||
|
|
||
| /** @internal */ | ||
| export function read(pointer: NativePointer, type: Il2Cpp.Type): Il2Cpp.Field.Type { |
There was a problem hiding this comment.
This was an interesting one. Parameters are different from eg Fields, in that they don't need to be dereferenced first. If you get a pointer that's meant to be a Il2Cpp.String, then no need to call ptr.readPointer() first.
Made this new behaviour backward compatible.
src/memory.ts
Outdated
| raise(`couldn't read the value from ${pointer} using an unhandled or unknown type ${type.name} (${type.typeEnum}), please file an issue`); | ||
| } | ||
|
|
||
| /** @internal */ |
There was a problem hiding this comment.
Err unrelated but could we have these exposed in the API? Bit more low level but super useful.
There was a problem hiding this comment.
That method is indeed here - if you invoke it, it works. It just isn't exposed (yet?)!
| wrapOnLeave(block: OnLeaveCallback<T>): ((this: InvocationContext, retval: InvocationReturnValue) => void) { | ||
| return (retval: InvocationReturnValue) => { | ||
| // TODO grab `this` pointer during `onEnter` | ||
| const thisObject = this.class |
There was a problem hiding this comment.
Since we derive this from the first argument sometimes, I suppose we'll always have to hijack both onEnter and onLeave at the same time, otherwise we can't propagate this to onLeave. Edit coming up...
|
The main reason why I didn't use Ref: frida/frida#266 (comment) However, a lot of time passed since that, and Frida might have implemented the support for it. |
1788eba to
d624db6
Compare
This isn't quite ready, but I wanted to start the conversation.
onEnterandonLeave(after Frida's own) are a bit less heavy-handed than replacing the whole implementation, and don't require explicit calls to the original method if you don't want to change output values. They're useful for inspection.It's now possible to do something like
However, one of my real reasons for writing them is that
set implementationappears to break some methods. There are some types and values for which the sequence offromFridaValue -> toFridaValueisn't idempotent, and breaks. I'll send a separate PR once I've fully figured out what's happening, but for now this PR helps me debug.I'll leave some comments inline. Also, I'm super not precious about what this API should look and feel like.